Lua templating/Tips and tricks
This page lists various tips and tricks for the creation, modding, and debugging of Lua-powered templates. Designing modules/templates Lua style guide It is usually a good idea to maintain some consistency in the design of modules, especially those used on a lot of pages. See this wiki's proposed Style guide for more information. Also try out a beautifier (e.g. lua-beautify). Loading and parsing data structured data The easiest way to load data is by saving it in a Lua table, storing it in a page and using mw.loadData( 'Module:Name' ) or require( 'Module:Name' ). But sometimes it may be useful to keep the data as it is and parse it. For example when retrieving JSON data, one way to quickly retrieve everything is to store the json in a page like Dev Wiki:Storage.js and then retrieve it using mw.title.makeTitle('pagename').getContent() and the decode function of the Module:Json or parsing it using Lua's string library. Note this will be an expensive call and will register as a link to that page. Require The lua engine only allows a maximum of (see this) calls to "require" (e.g. require("Module:zoo")). Types of modules There are three types of modules: * Global modules '''- these are stored in dev.wikia.com, and can be either modules for templates, or helper modules. They are typically loaded using the syntax like 'require("Dev:ModuleName")' e.g. require("Dev:Utility") . Note that this is case sensitive. * '''Modules for templates - these modules must contain a frame argument in one of the functions. * Helper modules - these modules aren't intended for inclusion on pages but to be used by other modules. Preview The preview button allows one to see what the module will display before it is saved. It is a good idea always to work with two pages, one with the actual module being edited and one test page that invokes the module. Rather than refreshing the test page a simple preview will save time. Arguments Parent or child arguments One important concept is the difference between parent (use through a template) and child parameters (using a module directly). Read more about arguments here. Incorrectly passed arguments These can cause problems if they contain special characters such as ='. The result will be that the module may not correctly interpret the passed arguments if they are, for example, part of a URL string, e.g. . Passing arguments from one module to another One of the greatest advantages of Lua is the ability to re-use existing code efficiently. So passing arguments to and from one module is important. There are several ways to achieve this: * Check if passed argument is a frame or regular object: -- Source: http://en.wikipedia.org/wiki/Module:Infobox -- If called via #invoke, use the args passed into the invoking template. -- Otherwise, for testing purposes, assume args are being passed directly in. if frame mw.getCurrentFrame() then origArgs = frame:getParent().args else origArgs = frame end * Create one function for the frame and a second for the arguments ('recommended): -- Module:Say Hello local p = {} function p._sayHello( name ) return 'Hello, ' .. name .. '!' end function p.main( frame ) local name = frame.args1 or frame:getParent().args1 return p._sayHello( name ) end return p * Use frame.preprocess()—this is not recommended because it is inefficient and fails to take advantage of powerful Lua methods: local p = {} function p.main(frame) local name = frame.args1 -- Calls Module:Say Hello return frame.preprocess( ' ' ) end return p Available frame API FANDOM may not always have access to the most recent MediaWiki's Scribunto API, so it's best to be aware of the differences when designing a module. The following table shows which frame methods are currently available on FANDOM, and provides links to the appropriate documentation. Debugging modules Cache One very important thing to remember when debugging a module is that FANDOM keeps a cache of data. So changes made in modules may not always be immediately visible in a page. One way to get around this is to append ?debug=true or ?action=purge (e.g. http://dev.wikia.com/wiki/Lua_templating/Tips_and_tricks'?debug=true') to all pages that are being debugged. See for more information. Debugging console * Debugging functions using the console - One can debug functions written in the module text area using the debug console. To do this one merely needs to call the function, e.g. p'''.helloworld('howdy'). Note that functions need to be part of the main table, specifically p, and functions outside this table cannot be called this way. * '''Console shows two types of errors - One of the error relates to a syntax problem in the console itself, and the other relates to errors in the module text area. Simply typing an expression will show one or both errors, e.g.: '='. * Print debug output - Output can be printed to the console using mw.log('test'). * Frame - The frame is nil (empty) using the debug console, as it is created during a module being used through #invoke. Emulating the frame object using the console A frame object is generally nil, but for the purposes of debugging on the console it can be emulated: local childFrame = { -- Child frame's arguments (change as needed) args = { 'es', 'en', 'n', 'n', 'n' }, getParent = function () -- Parent frame's arguments (change as needed) local pArgs = { 'es', 'en', 'n', 'n', 'n', '2011-06-29' } return { args = pArgs } end } -- Returns all values in parent frame function test( frame ) local args = frame:getParent().args local output = mw.text.listToText( args ) mw.log( output ) end test( childFrame ) Testing modules One way to test modules is by emulating the template call as shown above. This will make it easier to preview the output before saving the page and deploying the module. Unit testing There are several ways of testing modules/functions therein. One way to achieve this is by using Wikipedia's "UnitTests" framework. Implementing modules Modules can either be implemented and used as stand-alone using or they can be used in conjunction with templates. Working with templates or pages While working with templates it is important to use the frame's parent, and to bear in mind that these modules may not work when called directly if they aren't coded properly: --Module:Hello local p = {} function p.main( frame ) local name = frame.args1 name = name or "" return 'Hello, ' .. name .. '!' end return p Template:hello output :Hello world output :